Skip to content

Add new rule to detect ransomware disabling backup/recovery services#1122

Open
0ameyasr wants to merge 4 commits intomandiant:masterfrom
0ameyasr:feature/ransomware-targets
Open

Add new rule to detect ransomware disabling backup/recovery services#1122
0ameyasr wants to merge 4 commits intomandiant:masterfrom
0ameyasr:feature/ransomware-targets

Conversation

@0ameyasr
Copy link

@0ameyasr 0ameyasr commented Feb 22, 2026

(Addresses issue #1048) Added a new rule to namespace impact/inhibit-system-recovery, namely disable-backup-or-recovery-services; Passes lints & references an existing sample in capa/testfiles (Ryuk / b87e9dd18a5533a09d3e48a7a1efbcf6.exe_). It aims to detect ransomware samples attempting to open and stop common backup or recovery services upon infection through static analysis of the sample's file scope. For patterns and mitigation, it refers Kasperky crimeware reports in pages 89/90.

Edit (Commit 2): Renamed rule to 'stop-backup-or-recovery-services' from 'disable-backup-or-recovery-services'
Edit (Commit 3): Fixed an initial misunderstanding I had about scope, potentially increasing detection precision

image image

description: the sample attempts to disable and stop backup and recovery services
scopes:
static: file
dynamic: unsupported
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the rule also work for function and call/span of calls scopes?

Copy link
Author

@0ameyasr 0ameyasr Feb 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I initially had tested the rule with scope static: function, and the rule failed to detect numerous obvious stop attempts in the Ryuk sample (because they were distributed across functions in the file), which I was using to verify whether it worked. I designed this rule for static analysis only (also primarily why I marked dynamic as unsupported, if that is acceptable) rather than runtime API calls, though a separate one for the latter could be written too.

@0ameyasr
Copy link
Author

0ameyasr commented Feb 22, 2026

(Edited, Update / Commit 3) I had this misunderstanding about the way the rule was detecting feature patterns in the file scope. Per my initial logic I had originally thought the rule would solely detect occurences in the pattern "stop_command service_name" as a local string together wherever present in the file, while it also actually allowed the stop command and service name to be present in separate locations in the file. I believe this would have increased false positives considerably, which is why I resorted to simplifying the feature rules to match the above pattern correctly. I think this is more precise than the earlier version. The scope of the rule still remains static:file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants